Loadstar 128 26/q26.d81/t.forum 26

Text File | 2022-08-28 | 7KB | 147 lines

                   L O A D S T A R    1 2 8    F O R U M

                         Compiled by Fender Tucker


Dear LOADSTAR 128,

    I'm surprised that the real problem with SIDEWINDER was brushed over so
easily in your answer to Thomas Houlihan.  It is certainly not the answer.
Using the LS 128 disk the SIDEWINDER program will print the template, but
loading and running the DEMO will only print garbage.

    My first trial was to make a copy using Copy It, then I tried another
file copy program.  In both cases, neither copied program would print
anything but garbage.  Somehow or other the LS 128 Presenter system must be
on the disk.

    I'm not a programmer, but I did discover that by making a whole disk
copy of the LS 128 disk, then scratching all of the non-SIDEWINDER files, I
could at least get the SIDEWINDER template to print, but not the demo.

    Will the REAL programmer stand up and correct this program?

                 Gino Mercuriali
                 Cedar Rapids IA

LS 128: Your troubleshooting techniques are good, Gino, but the problems
you are having stem from a programming technique that is controversial and
needs attention.  Here's what's happening:  When you run the SIDEWINDER
program, the ML files get loaded and the program works.  Then you quit
SIDEWINDER and load and run the DEMO.  Unknown to you (and everyone), the
ML areas are then corrupted.  But when the DEMO gets ready to load the ML
again, it checks certain memory locations to see if the ML is in place.  If
the checks are okay, then the ML doesn't have to be reloaded.
Unfortunately, the DEMO checks tell the DEMO the ML is in place, which it
is, but it's corrupted.  It should be reloaded.

"Checking before loading" is a useful, friendly technique but only if it
works all the time.  In my opinion, it's better to make the user wait each
time for the ML to load than to take the risk of the ML not working.  These
days, slow disk loads are only a problem for those with old-fashioned
systems without JiffyDOS.  Try getting rid of the "if x<>255 then" in line
520, and "if x<>128 then" in line 640 in the DEMO and the program should
work, even if you just ran and quit the SIDEWINDER program.

Another thing you can do is to turn your computer off and back on before
running the DEMO.  I should have noticed that the author's check system was
liable to cause trouble and got rid of the checks before publication.
Sorry.

Getting SIDEWINDER to print the proper size with a 24-pin printer seemed to
be a bigger problem, but thanks to Art Johnson of Fremont NE, here's a
solution.  Change the two CHR$ values that follow the CHR$(27) in line 960
to 43 and 35, rather than 65 and 7.  This sets the line spacing to 35/360
inch, perfect for printing in the IBM or Epson mode with the interface set
to transparent.

Thank you, Art!!!  This is also something I should have noticed.  I figured
the line spacing setup was in the ML but ed bell wisely did it in BASIC
before calling the ML.


Dear LOADSTAR 128,

    I have a 1571 and a CMD FD-4000 drive.  When I use the 1571 with
FIDUCIARY on LS 128 #23 I have no trouble, but when I use the FD-4000 I get
the message "NOT ENOUGH ROOM - REQUIRE 258 BLOCKS" when I try to Initialize
Transaction.  Is there any way I can use FIDUCIARY with an FD-4000?

                    Robert J. Follett
                    Janesville WI

LS 128: I tried every way I could think of to get FIDUCIARY to work on an
FD drive but I'm afraid that Lee Clinton inexplicably checks for a 1581
drive, rather than checking the disk to see if there's enough blocks free.
At least that's my theory.  Using FD-TOOLS you can create a disk that
exactly emulates a 1581 disk, but the drive is still an FD drive.   Since
we push FD drives, this especially disappoints me.  Lee wrote FIDUCIARY
before there were FD drives, but if Lee were still programming for the 128
I'd ask him to change his method of checking the disk.


Dear LOADSTAR 128,

    Bob Cook's MINEFIELD on LS 128 #20 is a great game but it's frustrating
when, upon finding a mine, the green box immediately pops upon the screen
before I can study the screen to identify my mistakes.  An ML patch to move
that field would be very much appreciated.

               J. D. Goss
               Kansas City MO

LS 128: It's that kind of day, I guess.  I asked Bob Cook to provide a fix
for this and here it is:

 (1) LOAD "minefield boot" but don't RUN it.

 (2) Add line 112:

     112 fori=0to10:poke12400+i,16:next

 (3) Scratch and save "minefield boot" with:

     goto10000

    This will place the green box at the top of the screen.  All of this
has inspired me to write the following manifesto about the ML/BASIC
question:

 Dear Programmers,

     Users may be impressed when they read that a program is "100% machine
language" but editors (at least this editor) would much prefer that the
only things done in ML are those things that CAN'T be done (or are too
slow) in BASIC.  If MINEFIELD were a BASIC program with ML routines for the
slow parts, it would be a snap to move the green box.  LOADSTAR asks for
source code for ML routines and programs (and Bob Cook never fails to send
it) but I have yet to find a machine language programmer who is any good at
editing other people's code.  ML programmers use a variety of assemblers
and numerous tricks that make it very difficult to edit.  I can look at any
BASIC code and tell what the function of that code is, but without well-
documented source code done in an assembler that Jeff Jones knows (that is,
EBUD), ML code is totally un-editable by us.  Even Scott Resh, self-
proclaimed ML guru, couldn't (or wouldn't) edit other people's ML code.
Whenever I asked him to do that, he'd end up rewriting the whole thing in
his own code.

    To me, the real power of an 8-bit Commodore computer is in its built-in
BASIC and its friendliness to editors and users who like having control of
programs.  Maybe I can influence you by saying:

    From now on I will pay more for hybrid programs (BASIC with ML routines
for the parts where speed is needed) than for 100% machine language
monoliths that can't be edited by me or anyone.

               Your editor, Fender Tucker

Disclaimer to Manifesto: I'm not talking about DAVE'S TERM 128.  There's no
way a BASIC program could approach DT128's power.  There may be little
things that you or I would like to change in it, but take my word for it,
we're much better off having it written in 100% machine code.

                       \\\\\ RETURN - Menu \\\\\